In a multimedia system, such as a set-top box (STB), for example where multiple chips on a board communicate with each other, the security of the interfaces between these chips have to be considered in determining the overall security provided by the system. In particular, when one chip is a master device and another chip is a slave device, and when the communication between the master and slave devices occurs over an easily tapped or hijacked medium such as the PCI bus, for example, steps may need to be taken to ensure that the slave device may not be controlled by an unauthorized device. This may be especially important when, for example, the master or host device may be responsible for providing network conditional access (CA) decryption on video/audio data received by the multimedia system, and then re-encrypting the original data using a local copy-protection (CP) method before communicating the re-encrypted data to the slave device. In this instance, an unauthorized user may recover the video/audio data when the data communication between the host and slave devices is compromised. In this regard, an unauthorized user may attack the slave device instead of the higher security host device to recover the original video/audio data with the CA encryption removed.
In master-slave device configurations on a multimedia system board, for example, often the slave device has limited processing capabilities and may not be capable of providing a full software layer. In these instances, the host device may be utilized to configure the slave device via a plurality of commands sent over a generic interface, such as the PCI bus, for example. This may result in an additional level of exposure to unauthorized users since the slave device may not be capable of distinguishing when commands are being sent from the authorized host device or from an unauthorized host device. Without being able to make this distinction, the slave device may be configured by another device on the PCI bus, for example, regardless of the device's authorization status.
Authentication generally refers to the method by which the slave device may ensure that a command being sent to it comes from a legitimate or authorized host device. A slave device may be enabled to accept command from a single authorized device. A generally utilized approach for allowing the slave device to authenticate the host device is to use some sort of public key/private key protocol, where host commands may be signed using its private key, and which are then authenticated by the slave device using the public key. However, without a common shared secret, this type of authentication may be subject to a “man in the middle” attack, for example. In such an attack, a device on the common bus may write a public key to the slave device, where the public key may corresponds to the unauthorized device's own private key, and thus enable the unauthorized device to issue commands that may be considered “authenticated” by the slave device. Another problem with this approach is that the public/private key pair is common for all devices. Therefore, if the private key is ever compromised, it will compromise the devices that utilize this scheme.
Another level of security may include a common secret that may be utilized to provide authentication between devices. In this approach, the host device may encrypt commands that may somehow incorporate the common secret and the slave device may compare this value to its internally stored common secret to ensure that the command originates from an authorized source. However, while a common secret may be useful for helping to keep the details of key exchange secure, exposure of the common secret will compromise the devices.
Another approach may involve the use of a unique per device pair, sometimes known as “pairing”, in order to ensure that for any given slave device there may a single master device. In many STB integrated circuits (ICs), an internal non-volatile memory, such as a one-time-programmable (OTP) or on-chip secure flash, for example, may be utilized to store secure root keys which may be unique for every chip. Utilizing this approach, both the host and slave devices may be programmed with the same secure root key. As a result, commands sent by the host device may be encrypted by, for example, some derivative of the secure root key. Since only a single master device has this key, the slave device may be assured that the command came from the single legitimate source.
However, “pairing” may have logistical and/or practical limitations. In most integrated circuit fabrication and assembly facilities, it may be very difficult to keep track of pairs of chips or devices throughout the manufacturing, validation, testing, and/or board mounting stages. In addition, different types of chips, as the host and slave devices generally are, may be manufactured separately, and a large amount of time and expense may be used to keep track of pairs of devices from two separate fabrication processes and/or sources in order to enable a “pairing” scheme.
Another type of exposure to unauthorized users faced by a slave device may be in the form of replay attacks. For example, when a particular command produces a desired result, an attacker that is tracking the system's activity may remember this command and may later issue the exact sequence in order to achieve the same result. In this regard, effectively reducing or eliminating the ability of unauthorized users to replay authorized command sequences in multimedia systems may enable secure communication interfaces between host and slave devices.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings.